应用层协议原理
客户-服务器体系
这种体系有核心——服务器。
客户之间不直接通信。
服务器具有固定地址。（一直是打开的）
P2P体系结构
应用程序在间断连接的主机之间使用直接通信。这些主机对称为对等方。
这种好处一个是不需要庞大的服务器设施和服务器带宽，这叫做成本有效；另一个是在增加请求文件（工作量）的同时能增加服务能力（为其他对等方分发文件），这叫做自扩展性。
但是也有坏处， 比如ISP友好。大多数住宅流量都是下载比上传多的，这和P2P的流量对称的特征不一。
进程通信
进行通信的实际上是进程而不是程序。
客户和服务器进程
在给定的一对进程之间的通信会话场景中，发起通信（请求联系）的进程称为客户，等待联系的进程称为服务器。举例：在P2P中，当进程A请求进程B发送特定文件时，进程A为客户，进程B为服务器。
进程和计算机网络之间的接口
套接字（socket）是一个软件接口，被用来让进程通过它向网络发送和接受报文。它是运输层暴露给网络层的API。
进程寻址
成功发送报文需要什么？1、主机的IP地址。2、目的地的端口号。IP地址是用来标识对方地址的，但是端口是干嘛的？如果一个计算机只从一个进程里接受文件，多个文件发送给这个计算机的时候会不会造成拥堵？一般而言，端口就是让主机运行多个网络应用的；不同的网络应用从不同的端口接受信息。
运输层提供API的服务类型
可靠数据传输：传输过程中比特可能会损坏 (0->1 或 1->0)。当然有些应用允许丢失(loss-tolerant application)，比如多媒体应用部分帧丢失。
吞吐量：可用吞吐量就是发送进程能够向接收进程交付比特的速率。比如因特网电话应用。具有吞吐量要求的应用称为带宽敏感的应用(bandwidth-sensitive application)。
实时：时延，就比如其决定了点兵的金币送给哪个英雄。
安全性：比如加密银行密码，不能明文通过网路发送。
因特网提供的运输服务
TCP面向连接（发送数据之前要告诉对方自己要建立一个传数据的连接）、全双工交换信息，提供可靠的数据服务（无差错、有序地传递数据），具有拥塞控制机制。
UDP无连接，不可靠，无拥塞控制机制。
应用层协议
应用层协议定义了运行在不同端系统上的应用程序进程如何相互传递报文。定义了报文类型、语法、语义、响应规则。
- 应用层协议和网络应用：应用层协议只是网络应用的一部分。如Web的应用层协议为HTTP，但Web应用还包括HTML、Web浏览器、Web服务器。
HTTP
全称为超文本协议（HyperText Transfer Protocol）。它基于运输协议TCP。
Web页面大多含有一个HTML基本文件以及几个引用对象（如图片）。HTML文件通过对象的URL地址引用页面中的其他对象。URL由两部分组成：存放对象的主机名和对象的路径名。如http://www.fishlemon.com/picture.gif，www.fishlemon.com就是主机名，/picture.gif就是路径名。
无状态协议意味着服务器向客户发送被请求的文件，并不保存客户的任何状态信息。HTTP是无状态协议。
如果每个请求/响应对是经过一个单独的TCP连接发送，称为非持续连接，如果所有请求经过相同的方法连接，那么称为持续连接。但要注意的是，这里没有讨论TCP之间的串并行关系。长连接和端连接
往返时间（Round-Trip Time, RTT）指的是一个短分组从客户到服务器再返回客户的时间。（这意味着忽略传输时间）传输文件的响应时间约为两个RTT加上服务器传输HTML文件的时间。见下图。
非持续连接坏处是：1、需要为每个请求的对象建立和维护一个全新的连接，则客户和服务器需要分配TCP变量和缓冲区，给服务器带来了严重负担。2、每个对象得到的时间均为两个RTT。持续连接的好处是负担小，坏处是只能串行（可以通过流水线，即多个请求一个接一个地发出、无需等待回答的方式来提高性能）。HTTP默认模式为带流水线的持续连接。一般来说如果一条连接经过一定时间间隔仍未被使用，服务器就会关闭该连接（通过 telnet之后放置一段时间能感受到）。
报文格式
HTTP请求报文
1
2
3
4
5GET /somedir/page.html HTTP/1.1
HOST: www.someschool.edu
Connection: close
User-agent: Mozilla/5.0
Accept-language: fr
响应报文
1
2
3
4
5
6
7
8
9HTTP/1.1 200 OK
Connection: close
Date: Tue, 09 Aug 2011 15:44:04 GMT
Server: Apache/2.2.3 (CentOS)
Last-Modified: Tue, 09, Aug 2011 15:11:03 GMT
Content-Length: 6821
Content-Type: text/html
(data data data data data)...
Cookie
这节很有意思。cookie技术有四个部件。
HTTP响应报文中有一个cookie首部行
HTTP请求报文中有一个cookie请求行
用户端系统中有cookie文件，由浏览器管理
位于Web站点的一个后端数据库
这节告诉我们，服务器之所以能够认出我是谁，不仅是由于他有一个对应的数据库，还因为客户（浏览器）告诉了服务器我是谁。这个信息的产生不是仅因为浏览器被监视了，而且浏览器主动暴露了自己的信息。
Web缓存
Web缓存器有自己的存储空间，保存最近请求过的对象的副本。当请求来临时，Web缓存器检查自己是否这个对象的副本，如果有就返回该对象，否则向初始服务器请求。
Web缓存器带来两个性能上的提升：1、用户响应变快。2、减少因特网的拥堵程度。
高速缓存保存的对象有可能陈旧的（保存后初始服务器中的原对象被修改），怎么办？在这种情况下缓存器保存好保存的时间，之后若再次被访问，缓存器问初始服务器是否有修改，初始服务器只告诉它yes or no，不包含请求对象。若为yes，则用GET方法请求。问初始服务器是否有修改的方法叫做条件GET。
FTP
FTP服务器在整个会话期间保存着用户的状态，如追踪用户在远程目录树上的当前位置。HTTP是无状态的。
FTP的控制连接贯穿整个用户会话期间，而数据连接是非连续的。
FTP使用（至少）两个并行的TCP连接来传输文件。一个是控制连接，一个是数据连接。控制连接用于传输如文件存取命令、改变位置命令等命令。数据连接用于实际发送文件。
因此，FTP的控制信息是带外(out-of-band)的，意思即为它使用了独立的控制连接。带内意思为同一个TCP连接中发送请求首部行和响应首部行，如HTTP。
因特网中的电子邮件
邮件主要组成部分有三个：
用户代理：用来从用户的主机上对邮件进行查、删等操作
邮件服务器：收发邮件、保存邮件，长期开启，以便用户代理访问它时能够响应
简单邮件传输协议：负责一封邮件从用户代理传到邮件服务器，以及从负责发送邮件的服务器传送到负责接收邮件的服务器的过程。
SMTP
1 | S: 220 hamburger.edu （建立TCP连接时的第三次握手） |
与HTTP的对比
拉协议举例：TCP连接是由想接收文件的机器发起的。比如HTTP由客户向服务器申请下载HTML。推协议举例：TCP连接是由想发送文件的人发起的。SMTP是推协议。
SMTP要求每个报文使用七位ascii编码。
SMTP把所有报文对象放在一个报文中，而HTTP对象把所有对象封装到自己的HTTP响应报文中。
邮件报文格式和MIME
每个首部必须包括一个From: 首部行和一个To: 首部行。格式为首部+换行+报文体（ascii编码）。MIME
邮件访问协议
由于SMTP是一个推协议，因此接收方的用户代理不能通过SMTP来向服务器申请接收邮件。因此出现了以下协议来帮助Bob将邮件从邮件服务器传送给PC。
POP3
分为三个步骤，特许阶段（明文通过用户名和口令鉴别用户），事务处理阶段（标记删除、取消标记删除、获取统计信息），更新阶段（双方结束回话、服务器更新代理所处理的操作）
1 | telnet mailServer 110 |
+OK 代表命令正常，-ERR 代表命令有误。
IMAP
解决了POP3的以下问题：
提供远程文件夹，并为报文指派文件夹
允许用户代理获取报文组件（如只获取首部、只获取文本不获取附件等）
基于Web
各种在线的邮箱网站，比如mail.163.com。
DNS：因特网的目录服务
这一小节特别重要，教会了我设计一个分布式系统的基本思想。
由于1、主机名(如cnn.com)并没有提供主机在互联网中的信息，且2、由不定长的字母数字组成，因此路由器难以处理。由此主机也可以用IP地址标识。
DNS和IP什么关系？
人们喜欢主机名，好记（比如bilibili.com）；但是路由器喜欢定长、有结构的IP地址。为了折中，DNS(Domain Name System)提供了主机名到IP的转换的目录服务。
DNS为：
- 由分层的DNS服务器实现的分布式数据库
- 一个使得主机能够查询分布式数据库的应用层协议
一些基本概念：
- 主机别名：一个主机能有一个或者多个别名。就比如本网站blog.fishlemon.com是Domain Name, 他的Canonical Name为rainorangelemon.github.io。
- 邮件服务器别名：想法同上。
- 负载分配：就是负载均衡，针对同一个规范主机名，提供多个IP服务主机，当客户对于映射某地址集合的名字发出一个DNS请求时，服务器循环回答这些服务器IP。
DNS工作原理
为什么要分布式？假定这个查询IP的数据库只有一个，那么会出现以下缺点：
- 单点故障。该数据库崩溃，因特网立刻崩溃。
- 通信容量限制。手游卡爆掉。
- 远距离的集中式数据库。中国人民肯定乞求把数据库放在中国，这样传播时延会比地球对面的同志们少好多。
- 维护。由于体积大，增删查耗费时间很大、很麻烦。
DNS缓存
比如本地DNS服务器缓存最近查询过的DNS回答中的信息，以便后来者再次访问时减少时间。我猜google.com的IP信息肯定是常驻在缓存中的。
DNS记录和报文
终于知道注册域名时dnspod上为什么要填CNAME类型记录了。开心！
插入记录过程：比如将关于com的TLD的DNS服务器的NS和A类记录插入根DNS服务器，然后将关于google.com的DNS权威服务器的NS和A类记录插入TLD服务器，最后将关于www.google.com的IP的A类插入权威服务器。
P2P应用
文件分发
假设$u_s$代表服务器的上传速率，$d_i$代表第$i$对等方的下载速率，$F$代表被分发的文件长度，$N$表示要获得该文件副本的对等方数量。
对于服务器-客户结构，$$D_{cs}\geq \max\left\{\frac{NF}{u_{s}},\frac{F}{d_{min}}\right\}$$
对于P2P结构，$$D_{P2P}\geq \max\left\{\frac{N}{u_{s}},\frac{F}{d_{min}},\frac{NF}{u_s+\sum_{i=1}^Nu_i}\right\}$$。
书中提到以上式子中$\geq$符号均可以实现为$=$号。看出P2P结构具有规模上的可扩展性，且能够保证时间的最低不随N的扩展而线性变大，因为至多比$\frac{N}{u_s}$小。这种扩展性的直接成因是：对等方除了是比特的消费者还是它们的分发者。
BitTorrent
- 洪流(torrent)：参与一个特定文件分发的所有对等方的集合。
- 追踪器：新加入的主机怎么知道该从哪些IP申请下载？追踪方负责跟踪正参与在洪流中的对等方，并将对等方的一个子集IP发送给新的对等方。
- 稀缺优先：比如新的对等方叫做Alice。Alice应当向她的邻居请求哪些块呢？BitTorrent采用申请那些在她的邻居（邻居指Alice得到的洪流IP表中的主机）副本数量最少的块。这很容易理解：防止这些副本由少部分主机持有，防止增加这些主机的上传负担。
- 疏通：Alice根据当前能够以最高速率向她提供数据的邻居，给出其优先权。比如Alice每10秒钟计算邻居接收到比特的速率，确定最高速率流入的4个邻居。这四个邻居叫做疏通。（这个策略帮助主机之间互惠，而不能搭便车），且每过30秒随机选择另外一个邻居发送块（对新加入的人友好）。
分布式散列表（DHT，Distributed Hash Table）
DHT可以用于BitTorrent的追踪器：键为标识符，值为对等方的IP地址。
PS：为什么独立域名连接到github pages时需要将一个CNAME文件放在对应的repository中？
举例：当你访问blog.fishlemon.com时，DNS查出有一条CNAME消息，显示blog.fishlemon.com的正规主机名为rainorangelemon.github.io，用户通过访问rainorangelemon.github.io，github知道用户想要获取blog.fishlemon.com的HTML文件，但他并不知道blog.fishlemon.com对应的HTML文件。
有人就奇怪了，github不是知道这个用户是rainorangelemon吗？直接从它的reporsitory里读HTML文件不就行了吗？为什么说github不知道blog.fishlemon.com对应的HTML文件？
我使用了在线的DNS查询，看到了以下DNS查询：
1 | rainorangelemon.github.io. 3600 IN CNAME sni.github.map.fastly.net |
可以看到，sni.github.map.fastly.net这个名字里并不包含任何关于rainorangelemon的信息，即，rainorangelemon.github.io.是没有一个专用的服务器的，他和其他用户共用一个服务器主机名。
那么sni.github.map.fastly.net怎么知道是请求blog.fishlemon.com的访问而不是请求blog.meow.com的访问呢？
他可以用HTTP首部行的host中读取信息，如：
1 | GET / HTTP/1.1 |
然后在海量用户的repository挨个查在CNAME中的信息，看是否包含blog.fishlemon.com这个信息，如果有，那么把这个repository中的HTML文件返还给客户，于是就有你现在浏览器上看见的这个网站了。